2. Understanding the Architecture of SQL Server Reporting Services 2008
SQL Server Reporting Services 2008 comes in various modes:
Native mode Report server runs as a stand-alone application server.
SharePoint Integrated mode Report server runs within a SharePoint farm and end users access reports via a SharePoint front-end.
Native mode with SharePoint Web Parts
You can use two special Web Parts in a SharePoint site to view reports
that are stored and processed on a report server that runs in native
mode.
For a thorough understanding of
the architecture, it is useful to start with an explanation of the
concepts of reports, data sources, and report models.
The SQL Server Reporting Services 2008 world revolves around reports that are defined in an XML dialect called Report Definition Language (RDL). RDL files contain a mixture of mark-up and data queries in SQL that are rendered to a variety of formats
by SQL Server Reporting Services 2008, most notably HTML but also
formats like Excel, PDF, CSV, XML, TIFF, HTML Web archive, and Word. In
case a specific scenario requires more output formats, you need to
either buy or develop custom report generators. The following code
listing displays a part of an RDL file.
<?xml version="1.0" encoding="utf-8"?>
<Report xmlns:rd="http://schemas.microsoft.com/SQLServer/reporting/reportdesigner"
xmlns:cl="http://schemas.microsoft.com/sqlserver/reporting/2010/01/componentdefinition"
xmlns="http://schemas.microsoft.com/sqlserver/reporting/2010/01/reportdefinition">
<AutoRefresh>0</AutoRefresh>
<DataSources>
<DataSource Name="DataSource1">
<ConnectionProperties>
<DataProvider>SQL</DataProvider>
<ConnectString>
Data Source=sharepoint2010;Initial Catalog=AdventureWorks
</ConnectString>
<IntegratedSecurity>true</IntegratedSecurity>
</ConnectionProperties>
<rd:SecurityType>Integrated</rd:SecurityType>
<rd:DataSourceID>c24ffda1-b9f1-45d6-9a53-47fcf5404110</rd:DataSourceID>
</DataSource>
</DataSources>
<DataSets>
<DataSet Name="DataSet1">
<Query>
<DataSourceName>DataSource1</DataSourceName>
<CommandText>
SELECT ProductID, Name, ProductNumber FROM Production.Product
</CommandText>
<rd:UseGenericDesigner>true</rd:UseGenericDesigner>
</Query>
<Fields>
<Field Name="ProductID">
<DataField>ProductID</DataField>
<rd:TypeName>System.Int32</rd:TypeName>
</Field>
<Field Name="Name">
<DataField>Name</DataField>
<rd:TypeName>System.String</rd:TypeName>
</Field>
<!-- The rest of the XML file is omitted for clarity reasons. -->
In SharePoint, RDL
files are stored in report libraries. In itself an RDL file is useless,
because it doesn’t contain information about specific data sources.
Therefore, every RDL file needs to be connected to a report data source
(RSDS) file. RSDS files are also known as data source definition files.
Such files contain information about the data source type (such as
Oracle or SQL Server) and specific information about the data source,
such as a connection string. In SharePoint, RSDS files are stored in
data connection libraries. You can edit them by opening the Item Action
menu of an RSDS file and then choose Edit Data Source Definition. Figure 4 shows a sample RSDS file that is opened in SharePoint.
Finally, you can have SQL
Server Reporting Services 2008 report models that are also stored in
SharePoint report libraries. Models are defined using an XML language
called Semantic Model Definition Language (SMDL), and the file extension for report model files is .smdl. Like reports, report models (also known as report schemas)
are linked to data sources, and they contain entities that represent
database tables. The SharePoint action menu contains an extra option
called Load In Report Builder that causes the Report Builder tool to load. The Report Builder (see Figure 5)
is a ClickOnce application, so if it hasn’t been installed already, it
will do so immediately. The Report Builder leverages report models to
allow end users to create and save their own reports based on these
predefined models by choosing relevant fields from the predefined scheme
and using them to generate customized reports.
A high-level overview of this architecture looks like Figure 6.
2.1. Clients Tier
You can use a multitude of
clients to interact with the report server. If you are only consuming
reports stored in SharePoint, all you will ever need to use is a
browser. Developers will use the Report Designer extensively; this tool
integrates with Visual Studio.NET and allows developers to create report
server reports and deploy them to SharePoint. End users who want to
create their own reports will use the Report Builder, which provides
on-demand report creation in an Office-like authoring environment.
Compared to the Report Designer, Report Builder is a simplified tool
that does not offer all the features that Report Designer does, but it
provides end users with an easy-to-use option to customize reports.
Alternatively, you can build or
buy custom rich clients or custom ASP.NET pages that interact with SQL
Server Reporting Services 2008 in the exact way that suits your company.
Rich clients can optionally leverage the ReportViewer Windows Forms
control; ASP.NET pages can use the equivalent ASP.NET ReportViewer Web
control. Both controls can render reports obtained from the report
server. The ReportViewer Windows Forms control renders reports on the
client side.
2.2. SharePoint Tier
The SharePoint part of the
architecture overview consists of SharePoint itself, complemented by the
Reporting Services add-in. The Reporting Services add-in needs to be
installed on every SharePoint Web front-end server and contains a report
viewer Web Part, reporting pages that can be used to manage the report
server, and a proxy that is able to communicate with the report server.
In addition, the SharePoint tier will also contain all the reports, data
sources, and report models.
2.3. Report Server Tier
The next part of the SQL Server
Reporting Services 2008 architecture is the report server itself. Since
the SQL Server Reporting Services 2008 release, the report server runs
as a stand-alone true middle-tier application that doesn’t have to be
hosted on a Web server. The report server accomplishes this feat by
integrating more closely with the operating system itself by using HTTP.SYS
directly. HTTP.SYS (or the HTTP protocol stack) is an HTTP listener
that is implemented as a kernel-mode device driver, a core component of
the Windows operating system. SQL Server Reporting Services 2008 also
reuses SQL Server’s networking stack, SQL Server internal components,
the SQL operating system, SQL Common Language Runtime (CLR), and SQL
Network interface. This allows SQL Server Reporting Services 2008 to
provide native support for ASP.NET, among other things.
The dependency SQL Server Reporting Services 2008 had on Internet Information Services (IIS) had several drawbacks, including the following.
The complexity of managing IIS led to increased support costs.
Other applications hosted on IIS were able to impact SQL Server Reporting Services 2008.
There were many settings in IIS that could impact SQL Server Reporting Services 2008.
The
requirement of installing SQL Server Reporting Services 2008 on a Web
front-end server sometimes completely blocked the deployment of SQL
Server Reporting Services 2008 in the enterprise.
Most common IIS settings, as
well as the NTLM, Kerberos, Negotiate, Basic, and Custom security modes
and SSL certificates, are supported in the new architecture. Note that
IIS settings that were not supported are now not allowed at all. This
holds true for the following settings.
Anonymous authentication
Digest authentication
Client certificates
Note:
The lack of support for
client certificates also means that smart card authentication is not
supported for SharePoint/Report Server scenarios in any way—not in the
Report Server application tier, and not in the SharePoint 2010 WFE.
SQL Server Reporting Services 2008 (sitting directly on top of HTTP.SYS)
and IIS (which also leverages HTTP.SYS) can coexist on the same server.
This doesn’t result in any conflicts, except for the scenario in which
the server consists of the combination Windows XP 32 bit/IIS 5.1.
Companies that have developer machines that match this configuration
should keep this in mind. In all other scenarios, SQL Server Reporting
Services 2008 and IIS can share a single port, and both SQL Server
Reporting Services 2008 and IIS make URL reservations in HTTP.SYS.
You can use wildcard
characters in URL reservations, but you should note that IIS only makes
weak wildcard reservations. A weak wildcard reservation uses the
wildcard character * to indicate that the reservation catches all
requests not handled by others. SQL Server Reporting Services 2008 uses
strong wildcard reservations by default. A strong wildcard reservation
uses the wildcard character + to indicate that the reservation catches all requests. As a result, URLs that can be handled by SQL Server Reporting Services 2008 will be handled by SQL Server Reporting Services 2008, because they take precedence over IIS virtual directories.
All URL reservations are
stored in HTTP.SYS and they must be reserved prior to being used. After
adding a URL reservation, HTTP.SYS will start to accept requests for
this URL. SQL Server Reporting Services 2008 stores copies of its URL
reservations in the RSReportServer.config file, and it tries to register
all URLs listed there at run time. This means, essentially, that SQL
Server Reporting Services 2008 uses a simplified version of IIS virtual
directories. In IIS, a virtual directory handles HTTP requests and can
have many settings. In SQL Server Reporting Services 2008, a virtual
directory is able to handle HTTP requests just as well, but from the
viewpoint of SQL Server Reporting Services 2008, the virtual directory is nothing more than a name.
Because SQL Server
Reporting Services 2008 doesn’t use and depend on IIS, it needs to be
able to handle authentication requests itself. Because of this, SQL
Server Reporting Services 2008 contains a new authentication subsystem
that supports both Windows-based authentication and custom
authentication.
2.3.1. Memory Management
Memory management has improved quite a bit in SQL Server Reporting Services 2008. The report
server now contains an infrastructure for process memory monitoring
that is dynamic and self-managing: it reduces throughput in memory
pressure situations. Also, report processing uses a file system cache to
adapt to memory pressure. To make it easier to monitor SQL Server
Reporting Services 2008, it is now also possible to receive memory
events from the server, and administrators are allowed to set minimum
(the amount that is minimally claimed by the report server) and maximum
(a threshold that the report server will never exceed) targets. This is a
huge advantage over previous releases, in which the report server took
all available memory.
You also can adjust the
settings for the application domain recycling behavior using the
RSReportServer.config file. This configuration file can be found at the
following location.
%ProgramFiles%Microsoft SQL Server \MSRS10_50.MSSQLSERVER\Reporting Services\ReportServer
The following code listing contains the configuration settings for the application domain recycling behavior.
<Service>
<RecycleTime>720</RecycleTime>
<MaxAppDomainUnloadTime>30</MaxAppDomainUnloadTime>
<!-- The rest of the XML file is omitted for clarity reasons. -->
</Service>
The RecycleTime element
specifies how often the application domain is recycled. The default
value is 720 minutes. The MaxAppDomainUnloadTime specifies the wait time
in minutes during which an application domain is allowed to shut down
during a recycle operation. The default value is 30 minutes.
2.3.2. Log Files
As a consequence of not using
IIS anymore, SQL Server Reporting Services 2008 can’t rely on the IIS
logging mechanism, so it has its own trace log file, called the Report
Server HTTP Log. You can find all of the SQL Server Reporting Services
2008 trace information about the RS service and background processing in
this log file. The actual name of the Report Server HTTP Log is
ReportServerService_HTTP_<timestamp>.log;
it is a file located in the LogFiles folder beneath the [SQL Server
instance]\Reporting Services folder. This file stores all records for
all HTTP requests and responses handled by SQL Server Reporting Services
2008 (except for request overflows and time-outs, because these types
of requests don’t reach the report
server). You need to enable this logging mechanism explicitly by
modifying the ReportServerService.exe configuration file, which is
located in the bin folder of the Reporting Services installation folder.
This configuration file also allows you to specify a different
file-naming convention. The ReportServerService configuration file is a
normal ASCII text file and can be opened in Microsoft Notepad or any
other text editor. Its format resembles the IIS W3C extended log file.
If you need more information about the Report Server HTTP log, refer to http://msdn.microsoft.com/en-us/library/bb630443.aspx.
The other report server log files are
Report Server Execution Log
Includes information about reports that are executed by SQL Server
Reporting Services 2008. This log file allows you to find out how often
reports are requested and how much time is spent processing reports.
Report Server Service Trace Log
Contains information about SQL Server Reporting Services 2008
operations and is ideal for debugging applications running within SQL
Server Reporting Services 2008 or investigating specific problems in SQL
Server Reporting Services 2008. This file is located in the LogFiles
folder of Reporting Services and is named ReportServerService_<timestamp>.log.
Windows Application Log Contains event messages. Use this log to find out about events occurring on the local report server installation.
Windows Performance Logs
Contain a set of custom Reporting Services performance objects that can
be used to monitor SQL Server Reporting Services 2008 performance. Use
this log to create performance logs; you can identify which performance
counters to collect.
Setup log files
Contain setup messages including warnings and other data for
troubleshooting. These files are created during the setup of SQL Server
Reporting Services 2008 and are located in a log folder at
%ProgramFiles%\Microsoft SQL Server\100\Setup Bootstrap\Log\. The name
of the log folder has the following format: YYYYMMDD_hhmmss. When Setup
runs in unattended mode, log files are created at %Temp%\sqlsetup*.log.
Note:
MORE INFO You can find more information about each of these logs on the MSDN SQL Server Developer Center at http://msdn.microsoft.com/en-us/library/ms157403.aspx.
2.4. Data Tier
The data section in the architectural overview consists of multiple data repositories that SQL Server Reporting Services 2008 needs to function in SharePoint integrated mode, including the following.
Report catalog The report catalog consists of two separate databases, the ReportServer database (RSDB) and the ReportServerTempDB
database (RSTempDB). The ReportServer database contains all kinds of
metadata required by SQL Server Reporting Services 2008, such as
execution log files. The ReportServerTempDB database stores temporary
snapshots while reports are running.
Report data This is the data coming from various data sources used in the reports themselves.
Report server configuration files and registry
SQL Server Reporting Services 2008 stores configuration information in
both the registry and in configuration files that are stored on the file
system. The modification of configuration files might be required in
more advanced scenarios. The MSDN article “Configuration Files
(Reporting Services),” which can be found at http://technet.microsoft.com/en-us/library/ms155866.aspx, contains more information about SQL Server Reporting Services 2008 configuration files.
SharePoint configuration database This database is where the configuration information for the entire SharePoint farm is stored.
SharePoint content database This database is where SQL Server Reporting Services 2008 reports are stored in SharePoint integrated mode.
2.5. Detailed Architectural Overview and Common Scenarios
Figure 7 provides a detailed architectural overview of the report server in SharePoint integrated mode.
This means that a single
server deployment of SQL Server Reporting Services 2008 contains a
SharePoint installation (including the Reporting Services Add-in), the
report server itself, and a database server holding SharePoint
configuration and content databases as well as the report catalog. The
data that SQL Server Reporting Services 2008 will report about is
typically stored in other places. This is shown in Figure 8.
In a scaled-out deployment
of SQL Server Reporting Services 2008, you will find multiple clients
connecting to a SharePoint farm. A load balancer divides traffic across
multiple SharePoint Web front-end servers. All front-end servers in the
SharePoint farm must have the Reporting Services Add-in installed.
Requests are passed on (also divided by a load balancer) to a report
server farm consisting of multiple report servers and a single report
catalog. In this scenario, it is also true that the data SQL Server
Reporting Services 2008 reports about is typically stored outside of the
SharePoint and report server farms. Figure 9 shows an overview of a typical SQL Server Reporting Services 2008 scaled-out deployment.
